home *** CD-ROM | disk | FTP | other *** search
/ Ham Radio 2000 / Ham Radio 2000.iso / ham2000 / packet / praf205e / protokol.doc < prev    next >
Text File  |  1995-04-01  |  8KB  |  250 lines
  1.  
  2.  
  3. posted by KC3ET @ KA3NVP
  4.  
  5. TRANSLATION BY ROBERT BARRY
  6. SEPTEMBER 28, 1989
  7.  
  8.  
  9.            PROTOCOL FOR COMMUNICATION ON THE RS232 CUT POINT
  10.  
  11. 1. Host - Terminal Interlink distinctions
  12.  
  13. Because and RS232 cut point can act as a node and as a terminal,
  14. some means for distinguishing the two modes must be provided.
  15. This is done simply at the input to the DCD of the SIO channel B.
  16. Normally, the RS232 cut point is in the terminal mode. Following
  17. instructions given in the hand book, a negative potential is
  18. provided to the DCD connection, and Interlink mode is indicated
  19. by this.
  20.  
  21. 2. Frame Format in Interlink Mode
  22.  
  23. All frames are sent as on an HDLC channel. The software makes
  24. no adjustments at Level-2 and higher. In Level-1, just the
  25. HDLC flag needs to be reset. Thereby, a simple variant of the
  26. HDLC protocol is attained.
  27.  
  28. All frames begin with STX = 0x02 and end with ETX = 0x03.
  29. Inside a frame STX is replaced DLE-STX and ETX is
  30. replaced by DLE-ETX. DLE (0x10) is extended to DLE-DLE.
  31.  
  32. For fault detection, the common CRC is not used. Since
  33. faults on an RS232 link are not very likely, a simple check sum is
  34. appended to the ETX. The check sum is 8 bits long and applies to
  35. all the information in the frame (without STX-ETX). The trailing
  36. DLE's are not included.
  37.  
  38. 3. Collision Avoidance.
  39.  
  40. With only two TNC's on an RS232, no protocol, obviously, is
  41. needed. All transmittals run quasi-full duplex. With more than
  42. two TNC's, a CSMA-CD driver (or controller) is used, which is
  43. controlled over RTS-CTS. Each TNC may only begin a send-cycle if
  44. it has through the CTS determined that the bus is free. It
  45. asserts RTS and loads the bus. Then a randomly determined time
  46. (from 2.5 to 25 milliseconds) is allowed to pass so that any
  47. other TNC's who are ready to send can recognize the change in
  48. channel status. If, during this wait time, some other TNC asserts
  49. RTS, then the send-cycle is broken.
  50.  
  51.  
  52.  
  53.  
  54.  
  55.  
  56.                       THE INTERLINK PROTOCOL
  57.  
  58. 0. Foreword
  59.  
  60. The nodes exchange a special protocol for information display.
  61. The frames of the protocol have a 0xCF as Level-2 protocol
  62. identifier. Each frame contains a special Transport Header after
  63. this Level-2 Header (AX.25), which consists of 20 bytes. Because
  64. the AX.25 protocol permits only 256 bytes of information, overly
  65. long User Frames are divided into two sections. TheNet takes care
  66. of this, so that the original size is retained. To keep best use
  67. of the network, no frames longer than 236 bytes are allowed
  68. (Mailboxes). Please note that the Level-2 frames used between two
  69. nodes have the call signs of both parties included (because there
  70. is no digipeater list), whereas in the Transport Header, the call
  71. sign of the level 4 partner appears.
  72.  
  73. Examples: DB0FD contains a frame for DB0KH from DB0FC, which must
  74. be sent to DB0FE, because DB0FE is the next neighbor on the path
  75. list. DBFD, then, appears in the Level 2 Header as the Sender,
  76. and DB0FE appears as the receiver. In the transport header,
  77. DB0FC is the Sender and DB0KH is the Receiver.
  78.  
  79. 1. Construction of the Transport Headers
  80.  
  81. The first 15 bytes are evaluated by all parties to find the
  82. optimum path. The remaining five bytes take care of failures
  83. between sender and receiver. (AX.25 is by definition failure
  84. free.) The error provision is necessary, because at Level 2, the
  85. system cannot know if the entire path exists or not. In case of
  86. sudden loss of path, the Receiver must have some means of sending
  87. back frames to the sender for reclaiming.
  88.  
  89.  
  90.  
  91. 1.1 Originating Node's Call Sign
  92.  
  93. Length, 7 bytes, normal AX.25 (packed bytes) format
  94.  
  95. 1.2 Target Node's Call Sign
  96.  
  97. Length, 7 bytes, normal AX.25 (packed bytes) format, EOA bit set.
  98.  
  99. 1.3 Remaining Packet Life Time
  100.  
  101. The Remaining Packet Life Time is initially set by the
  102. originating node, and it is reduced by one by each transporting
  103. node. When the value reaches zero, the packet is destroyed. No
  104. error message results. This leads to one-way-paths. For example:
  105. DB0FC initializes its packet to a remaining life of 64, but DF6LN
  106. uses 10. The path between DB0FC and DF6LN has 15 intermediate
  107. nodes. A packet from DB0FC arrives with a remaining life of 49,
  108. but the reverse message is destroyed in passage because 15 > 10.
  109. A life time limit is necessary to forestall perpetual loops in
  110. the system.
  111.  
  112. 1.4 Four bytes with meaning depending upon each Opcode
  113.  
  114. These bytes are called B1, B2, B3, B4, in the order they appear in
  115. the frame. In each virtual channel, two bytes are used by the
  116. sender and receiver for identification, at the time that the
  117. channel is constructed at Level-4. One of the bytes of the index
  118. is the running count in the circuit list. The other, ID, byte, is
  119. a random number, to prevent ghost frames from a prior message
  120. from circuilating in the system.
  121.  
  122.  
  123. 1.5 Flags and Opcodes (1 Byte)
  124.  
  125. The lower four bits give the Opcode. The upper four bits are
  126. flags.
  127.  
  128. 1.5.1 Opcodes
  129.  
  130. Presently, only six of the possible 16 Opcodes are defined.
  131.  
  132.  
  133. 1.5.1.1 Opcode = 1  Connect Request
  134.  
  135. Created for a Level-4 Connection.
  136.  
  137.    B1 = My Index
  138.    B2 = My Id
  139.    B3 = not defined
  140.    B4 = not defined
  141.  
  142. The frame has the following information:
  143.  
  144.     Proposed Window Size, Level-4 (1 Byte)
  145.     For better utilization of the system at Level-4, to
  146. permit more frames to be interjected. This costs RAM. Each Sysop
  147. on the system must make his own choice.
  148.  
  149.     Call sign of the End User. (7 Bytes, AX.25 format with
  150. packed bytes)
  151.  
  152.     Call sign of the Sender Node, (7 Bytes, AX.25 format with
  153. packed bytes)
  154.  
  155. 1.5.1.2 Opcodes = 2  Connect Acknowledge
  156.  
  157. Answer to a connect request. The choke bit shows, in this case,
  158. that no free places exist on the free list, and the connect
  159. request is declined.
  160.  
  161. The information in the frame is:
  162.     Unified (or agreed) window size, Level 4 (1 Byte)
  163.     The unified (or agree) window size is never greater than
  164. the proposed window size.
  165.  
  166. 1.5.1.3 Opcode = 3  Disconnect Request
  167.  
  168. A directive to relese the Level-4 connection. The order can
  169. come from either end of the connection. The Receiver is ordered
  170. to send along any intermediate information and then to disconnect.
  171.  
  172.     B1 = Your Index
  173.     B2 = Your Id
  174.     B3 = not defined
  175.     B4 = not defined
  176.  
  177. The frame contains no information.
  178.  
  179.  
  180. 1.5.1.4 Opcode = 4  Disconnect Acknowledge
  181.  
  182. Assers that a Level-4 connection has been cut.
  183.  
  184.    B1 = Your Index
  185.    B2 = Your Id
  186.    B3 = not defined
  187.    B4 = not defined
  188.  
  189.  
  190. 1.5.1.5 Opcode = 5  Information
  191.  
  192. In these frames, information is translated.
  193.  
  194.    B1 = Your Index
  195.    B2 = Your Id
  196.    B3 = Running number "send sequence"
  197.    B4 = Running number "receive sequence"
  198.  
  199. Each frame is given a B3 number as it is sent. This serves as
  200. the value for the receiving frame of the same Level-4
  201. connection to (B4 - 1). This value corresponds to the Level-2
  202. value with the change that the "send sequence" does not run from
  203. 0..7 but rather from 0..255.
  204.  
  205. 1.5.1.6 Opcode = 6  Information Acknowledge
  206.  
  207. While the status of the contained information is implicit in the
  208. Info Frame, in one-sided data flow, this item is still necessary,
  209. acting as an extra confirmation.
  210.  
  211.    B1 = Your Index
  212.    B2 = Your Id
  213.    B3 = not defined
  214.    B4 = Running "receive sequence" number
  215.  
  216. This frame contain no information.
  217.  
  218. 1.5.1.7 Not Defined Opcodes
  219.  
  220. All other Opcodes indicate that the frame has been destroyed by
  221. the Receiver.
  222.  
  223. 1.5.2 Flags
  224.  
  225. The upper four bits in the Opcode Byte are reserved for flags.
  226.  
  227. 1.5.2.1 Bit-7  Choke Flag
  228.  
  229. The node does not have enough memory free to take in more
  230. information for the present Level-4 connection.
  231.  
  232. 1.5.2.2 Bit-6  NAK Flag
  233.  
  234. Contrary to what was said above, the Receive Sequence is not used
  235. as confirmation but as a directive that the Frame having this
  236. number is to be retained.
  237.  
  238. 1.5.2.3 Bit-5  More Follows Flag
  239.  
  240. The current frame must be divided. All following frames
  241. including the first one not having this flag are to be
  242. concatenated into one by the receiver.
  243.  
  244. 1.5.2.4 Bit-4  Not Defined
  245.  
  246.  
  247. END
  248.  
  249. (de:DF2AU)
  250.